TOS Silver 2000/TOS Silver 2000.iso/Anwendun/Pov/POVTOOLS/TOOLS/XTAL4POV/XTAL4POV.DOC

Text File | 1995-11-25 | 11.2 KB | 213 lines

XTAL4POV Ver. 2.0


This program generates POVRay 2.x data files of three-dimensional objects
with crystallographic symmetry. There is absolutely no need of knowing
anything about crystallography to use this program successfully and create
perfect crystal shapes. But for those who _want_ to know about crystallo-
graphy, the file INTRO.DOC contains some very basic information. The program
was originally written for my personal use in teaching crystallography, but
since I got access to the UseNet some months ago, I realized from the DKB
mailing list and comp.graphics.raytracing that other people might as well be
interested in this. So I changed the program messages from german to english,
added some documentation, and released the whole package ( .exe, source,
documentation, and data files) to the public domain. Feel free to do with it
whatever you want, including generating data files for POVRay. But be warned:
this program may contain bugs, and I would like to hear about these, though
I cannot guarantee I'll have the time to fix them.

        THIS PROGRAM IS FREE SOFTWARE AND COMES "AS IS" WITH ABSOLUTELY
        NO WARRANTY; WITHOUT EVEN THE IMPLIED WARRANTY OF MERCHANTABILITY
        OR FITNESS FOR A PARTICULAR PURPOSE. USE IT AT YOUR OWN RISC!

(O.K., I hope that's enough to get off the hook.)

System requirements: Any PC-AT compatible should do.

The program was compiled with MS C 6.00.






Usage:

        xtal4pov <-ך

The program will show a list of the seven crystal systems and their
associated 32 crystal class symbols, and ask for input of one of the symbols.
Chose one, and type it in EXACTLY as shown in the list, then press <return>.
Next, the program asks for input of the Miller indices hkl. Type in three
integer numbers between -98 and 98 with blanks between them, and press
<return>. The program will show a list of the generated Miller indices
(actually: crystal faces), the number of generated faces, and the scale
factor, and asks for a new set of indices. Type in a new set, or type
"99 0 0 <return>" for quitting. Then the program informs you that the data
have been written to the file "crystal.inc", and exits. BTW, with real
crystals, h, k, and l are always small numbers, say, between -10 and 10,
but this is just a rule of thumb, and nothing forbids the use of larger
numbers.

If you wish to generate a new data file, and want to keep the old one, be
sure to rename it to something else, for it will else be overwritten without
asking.

The resulting file "crystal.inc" contains a header (commented out), and one
or more #declare'd intersections of planes. The identifiers of the declara-
tions look a little bit odd, but contain unique information: they are com-
posed of the crystal class symbol you typed in, an underscore character, and
the initial Miller indices. Unfortunately, POVRay doesn't like minus signs
in identifiers, so all minus signs you typed in are converted to underscores.
The body of the declaration contains the number of planes you saw on the
screen in POVRay 2.0 format, with the "scale" value as distance. This scaling
has the purpose to keep all objects at about the same size, in fact, make
them fit into the unit cube. This is done using a very rough method, so it
may not always work very well. This file can be #include'd into a scene file
without further work.

That's all you _need_ to know.

But maybe you _want_ to know more? O.K., here we go. First, for those really
interested, there is a file INTRO.DOC, which contains some hopefully useful
information on the crystallographic background of the program. Don't be
afraid, I kept it as basic as I could.

Then, why did I write this program? Well, actually I wanted to make a simple
scene containing the five Platonic Solids as an overhead transparency for my
annual course in Elementary Crystallography. I thought this was not a big
deal, for the necessary objects were already there, in SHAPES2.INC. But soon
I realized that the shapes themselves were o.k., but the orientations with
respect to the coordinate system were wrong from a crystallographer's point
of view. Moreover, the method of generating the shapes by rotating planes
over and over seemed far too complicated. There is an easier way to make
crystals in POVRay.

In crystallography, we describe a plane using the so-called Miller indices
(neither Mike nor Henry, but William), a triple of integer numbers. These
are calculated as the reciprocal values of the axis intersections, i.e. we
measure on each crystal axis the distance from the origin to where it is cut
by the plane, take the reciprocals, and make these to integers by multiplying
with an appropriate number. Of course, this number must be the same for all
three values. Due to the special properties of crystals, this works always
for crystals. Well, and where's the trick? In an orthogonal coordinate sys-
tem, the Miller indices represent the direction vector of the normal to the
plane, and that's exactly how planes are described in POVRay! So, to make a
crystal shape in POVRay, one needs only to know the Miller indices of all
faces, assign an appropriate distance to them, and make an intersection of
planes with the Miller indices as direction vector. No rotations anymore, and
as we calculate the Miller indices relative to the axes, all shapes are
properly aligned. So this is what the program mainly does: For a given
symmetry, represented by the crystal class symbol, it calculates the com-
plete set of symmetry equivalent planes, the crystal form or crystal shape,
for a given starting Miller index triple.

This works fine for cubic, tetragonal and orthorhombic crystals, as these
have orthogonal coordinate systems. For crystal systems with one or more
angles being not equal to 90 degrees, the Miller indices no longer represent
the plane normals, so one has to make a coordinate transformation. This is no
big deal, as long as one knows the ratios of the respective axes and the
angles between them. For the hexagonal and trigonal system, there's no pro-
blem, the ratio is 1 and the angle is 120 degrees in all cases, but in the
monoclinic and triclinic system, these values vary. So here I come to the
point where I have to admit I've been a bit lazy. The coordinate transforma-
tions for hexagonal and trigonal crystals are built in to the program, but
for the other two systems, they aren't, because for this it would have been
necessary to let the program ask for the axis ratios and the angles. But as
I think one wants to have shapes with high symmetry in raytracing, I decided
not to invest further work in this. Who wants to trace a monoclinic crystal?
However, the generation of Miller indices works correctly in both cases, so
one could do the transformation by hand. Maybe one would do this for mono-
clinic, but as in the triclinic system every crystal form is either a single
plane or a parallel pair of planes, it's not worth the effort.

Now you know what's going on. But before I give you some hints what to do
with the data files, there's something more to say. As a matter of fact,
some of the data sets, or to be more precise, quite a lot, describe objects,
which are infinite in one or even two directions, so you have to combine
these with appropriate other forms to get finite objects. There are lots of
possible combinations, and as I don't want to write a novel here, I recommend
you play around and find out for yourself. BTW, in the cubic system, all
forms are finite.

Well, and now some bad news. Perhaps you may already have wondered, why I
emphasize the term "crystallographic" that strongly. The reason is, that
crystallographic symmetry is only a small subset of all possible symmetries,
and many other symmetries don't use integer Miller indices, so their incor-
poration into the program would have required a major rewriting. Unfor-
tunatly, just the two famous Platonic Solids Regular Dodecahedron and
Icosahedron require non-integer, even irrational, indices, and thus cannot
be generated by the program. Yes, you've heard right: These two shapes can
never be the shapes of naturally grown proper crystals! But for your con-
venience, I have included a file PLATON.INC, which contains all five shapes,
the non-crystallographic ones being handcarved, in their proper relative
orientations.

Well, and now, what to do with the data. First, of course you can use them
as you like, scale them, rotate them, and even change the distances of single
planes. No one has anything against it. We aren't here to do serious science,
but to create good-looking pictures. It's only, at the moment, I can't give
you anything else but a tool for creating scientific data, because this
program has it's origin in a real crystallographic program for computing
interfacial angles and the like.

But although you aren't bound to adhere to crystallography, maybe there are
one or two people out there, who at least want to know how to treat the data
in a crystallographically correct way. Here are some hints.

Never construct a crystal by using shapes from different crystal classes.

Cubic crystals must always be scaled evenly in all three directions.

Hexagonal, trigonal, and tetragonal crystals must be scaled evenly in x and
y, z can be chosen at will.

Orthorhombic, monoclinic, and triclinic crystals can be scaled in any way.

To avoid scaling problems, I recommend the following procedure for hexagonal,
trigonal, tetragonal, and orthorhombic crystals: first, apply identical
scalings to all shapes you want to use in a crystal, and then use even
scaling to put the shapes together the way you want.

Well, and now I have a problem. As the data for monoclinic crystals don't
contain the angle, there is no simple way in POVRay to produce a correct
monoclinic crystal. But anyway, we can use a workaround, and though it's
not correct, no one will be able to notice it. First, scale all shapes you
want to combine by the same amount, preferrably using different values for
x,y,z. Then rotate all shapes, for which l (=z) is not zero, around the
y-axis by the desired angle. This will, of course, change the values of
the Miller indices, and you are quite likely to produce non-integer indices,
but as no one will ever measure the angles between the faces in your ray-
traced image, you will be safe. For combining the shapes to a crystal,
scale them now evenly in all directions, and the result will look quite
monoclinic.

And for triclinic crystals? Scale and rotate as you wish. The result will
be triclinic whatever you do, though it's certainly not correct from a crys-
tallographic point of view. But who cares?


To do:

1.  Correct handling of monoclinic and triclinic system, if there is demand.

2.  Inclusion of non-crystallographic symmetry.

3.  Some sort of wire-frame previewer. But this will surely be quite a bit
    of work, and I hope, the POVGUI project will take this over.


I hope, this program, though limited, will be useful, and I would greatly
appreciate your comments, bug reports, etc.


E-mail: [e-mail]

Snail mail: Klaus Kosten
            Am Ginsterberg 13
            D-52477 Alsdorf
            Germany